主题
对比 JavaGuide《多 Agent 协作系统设计》、二哥与小林《Multi-Agent》《协作与动态切换》《子 Agent 超时失联》《任务拆分》。
多版对比
何时拆，两边一致：JavaGuide 说先用单 Agent / Workflow 验证，只有环节需要不同工具、权限或上下文才拆；二哥给了经验阈值（工具不超过十个、领域单一就别拆）和口诀「省下 Token 是正道」。这是设计题的第一答案。
架构模式，深度悬殊：二哥讲了两种——编排器中心调度（拆任务 → 语义匹配派活 → 子 Agent 独立上下文执行、互不通信全走中转 → 汇总再综合一次）和 Handoff（直接传控制权，客服场景常用，但要防 A→B→C→A 的死循环）、Pipeline（固定链路）。JavaGuide 给了九种编排模式，更关键的是把二哥没碰的深水区补全：状态共享、冲突处理、失败恢复。
JavaGuide 的三个独有设计判断（面试深水区）：① 子 Agent 之间传任务契约（允许什么工具、输出什么结构、超时和重试预算）和结论 + 证据，不传完整对话——隔离上下文本来就是拆分的目的；② 冲突分四类对症下药：状态写冲突用版本号、观点冲突用归并器、所有权冲突用租约、副作用冲突用幂等键；③ 失败按类型分治，配 Checkpoint 和状态机，不能指望「再跑一遍」。
小林：在 JavaGuide 的方向上更硬核。①通信方式二分给选型：消息传递（解耦，像发邮件）vs 共享状态（直接，像白板），按依赖强弱选；共享状态要分层、只追加不覆盖、错误也写进状态。②强判断：去中心化拓扑「生产几乎没人用」，几乎都是 Orchestrator。③防旧实例复活：租约 + 递增 generation（fencing token）——心跳中断不等于已停止。④独有坑：Git 能合并文本冲突但查不出语义冲突（改接口和旧调用方各自「顺利」合并，程序已坏），必须唯一 Integrator 按依赖序合并 + 质量门禁。⑤静态 DAG 拆分在依赖稀疏、I/O 为主的场景并行能降 40-60% 延迟。
结论：何时拆用两边的经验值开场，架构用编排器中心 + Handoff 防环，深水区把「传契约不传对话」和 fencing token、语义冲突、幂等键连起来讲——这是全组题最能拉开差距的部分。
最优题解
先说什么时候拆：单 Agent 装不下（上下文爆、工具杂、权限要隔离）才拆，能不拆就不拆——每多一个 Agent 就多一倍协调成本。生产里最主流的是编排器中心：主 Agent 拆任务、按各子 Agent 的职责描述派活，子 Agent 各自独立上下文执行、互相不直接通信，结果以「结论 + 证据」的结构回传，最后由主 Agent 综合或再调一次模型归并。要直传控制权就用 Handoff，但必须防回环死循环。
拆开之后真正的难点是协作质量：子 Agent 之间传契约和结论，不传聊天记录；并发写共享状态加版本控制，副作用用幂等键，同一个任务派给谁要有租约防重复执行；失败分清是工具挂了、超时了还是结果质量不行，前两者重试，最后一种要换策略或者转人工——每个子任务要有 Checkpoint，别整链重跑。
追问链
追问：子 Agent 之间为什么不直接通信？ 参考答：隔离上下文是拆分的主要目的之一，直接通信等于把上下文又搅在一起，还引入消息乱序和一致性负担；统一走编排器中转，状态有一处权威，出问题 Trace 也好查。
追问：两个子 Agent 改同一个文件/状态怎么办？ 参考答：按冲突类型处理——并发写用乐观锁或版本号，谁该改什么是所有权问题用租约，对外副作用用幂等键防重放；设计期就划定所有权比运行期仲裁便宜。
我的理解
这题的答题梯度：说出「编排器 + 独立上下文」是及格，讲得出「传契约不传对话」是良好，能主动展开冲突四分类和失败分治是优秀——后两块 JavaGuide 独有，二哥完全没碰，恰好是「真设计过多 Agent」和「看过介绍视频」的分水岭。二哥的 Handoff 死循环警告和「省 Token」口诀留作开场钩子。